docs: refactor service registration brief to HTTP traffic metering#181
docs: refactor service registration brief to HTTP traffic metering#181JoseSzycho wants to merge 10 commits into
Conversation
…e diagrams and Taskfile automation This changes replaces the service-catalog-registration with documentation more focused in the architecture design and implementation
JoseSzycho
changed the base branch from
main
to
feat/service-catalog-registration-design
scotwells
left a comment
scotwells
left a comment
There was a problem hiding this comment.
Directionally the architecture looks good. Let's just clean up some of the implementation details. We want to keep this document product / consumer focused.
|
Following on from the pipeline shape — the piece worth nailing down is how the log line gets the metadata embedded in the first place, since the project isn't something Envoy knows on its own. Project identity lives on the namespace ( The natural place to do that is the extension server proposed in #187. It already injects per-route So rather than enrich anywhere downstream, we piggyback on #187 to stamp the metadata at build time and let it fall through into the log line. |
…tions for HTTP traffic metering
|
@scotwells I just updated the enhancement, and I have a working implementation here: Could you please review the Design Details I introduced in the previous commit? I propose to different alternatives. Will wait to hear from you in order to continue with the implementation. |
| 1. **Network Services Operator (controller).** When the operator reconciles a | ||
| customer `HTTPRoute` into its downstream representation, it injects the | ||
| project name as a request header (`x-datum-project-name`) via a | ||
| `RequestHeaderModifier` filter on each route rule. The project name is read | ||
| from the upstream cluster identity (the Milo project name) that the | ||
| operator already holds while mapping upstream → downstream resources. Routes | ||
| that already define a `RequestHeaderModifier` are merged into rather than | ||
| duplicated, since Gateway API permits at most one such filter per rule. |
There was a problem hiding this comment.
While this approach works, I believe the approach in #181 (comment) would be better since it doesn't require exposing billing metadata through headers seen by end users.
With the header approach, we would have to prevent the user from ever specifying this header in their request since we use it for billing attribution. Otherwise we could potentially bill the wrong project for an HTTP route.
There was a problem hiding this comment.
thanks for the fast review. Will set this PR on draft and wait till the extension server to be on place for doing the final tweaks into the documentation.
There was a problem hiding this comment.
@scotwells the extension servers works correctly. I followed the approach you recommended in #181 (comment), and was able to correctly inject the project_name in the metadata.
Now the project_name is available in the per request access_logs.
This PR #188 illustrates this. I crated the manifest for deploying the extension server in a dev environment, and was able to perform the e2e integration test for verifying the the updated Design Details described in this commit 320d46a
Will wait for your review so I can proceed with the complete implementation of metering the HTTP Usage.
…p-traffic-metering Signed-off-by: Jose Szychowski <joseszychowski@gmail.com>
2 participants
Warning
In
pausetill #187 is on place#181 (comment)
This PR refactors and expands the initial service catalog registration design brief into a structured, standard enhancement proposal focusing on HTTP Traffic Metering for Network Services.
It addresses and resolves all open questions (OD-1 through OD-8) carried over from the previous design brief.
Related to:
Working implementation using OTLP Transport: